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1.  Summary 


Android  Smartphone  devices  provide  a  mobile,  powerful,  versatile  and  relatively  inexpensive 
computing  platform  that  is  potentially  well  suited  for  use  by  the  military.  Applications  (“apps”) 
are  relatively  easy  to  develop  and  deploy  for  tailored  military  use.  An  additional  benefit  to  the 
military  is  that  many  of  today"s  Soldiers  are  already  familiar  with  the  operation  of  these  types  of 
devices  so  little  training  is  required.  On  the  downside,  screen  sizes  can  be  relatively  small,  so 
design  of  input  and  output  screens  must  be  carefully  thought  out.  This  report  will  discuss  the 
Android  Smartphone  capabilities  as  relevant  to  the  military  for  providing  weather  and  weather 
impacts.  An  actual  app  that  has  been  developed  to  provide  heat  stress  guidance  will  be  examined. 


2.  Introduction 


There  are  situations  when  Soldiers  do  not  have  access  to  computer  workstations  or  even  laptops 
but  still  require  intelligence  regarding  weather  and  weather  impacts  on  their  missions.  Remote 
operations  in  Afghanistan  or  elsewhere  would  certainly  qualify  as  such  a  situation.  Under  these 
circumstances,  handheld  computing  devices  may  be  able  to  provide  critical  information  with 
only  simple  locally  available  inputs  (negating  the  requirement  for  a  network  connection).  While 
there  are  numerous  mobile  computing  device  platforms  that  could  provide  this  information  (e.g., 
personal  digital  assistants  [PDAs],  smartphones,  Apple  iPhones  and  iPod  Touch  devices,  etc.), 
this  report  will  focus  on  the  Android  operating  system  based  smartphone.  Earlier  tech  reports  (i, 
2)  specifically  discuss  PDA  and  iPhone  iPod  Touch  capabilities  and  relevance. 

In  2009,  the  U.S.  Army  Research  Laboratory  (ARE)  Battlefield  Environment  Division  was 
requested  to  support  the  Army  sponsored  All  American  Bowl  (AAB)  high  technology  exhibit  in 
San  Antonio,  TX  in  January  2010.  Although  existing  applications  existed  on  the  PDA  (including 
the  fielded  Mobile  Artillery  application),  it  was  felt  that  demonstrating  an  application  on  the 
fairly  new  and  very  popular  Apple  iPhone  or  iPod  Touch  would  generate  additional  interest  from 
both  the  military  and  the  general  public  (the  AAB  exhibits  were  open  to  the  public).  Thus,  the 
prototype  Hot  Environment  Assessment  Tool  (HEAT),  was  designed  and  developed  as  a  test 
application  to  host  on  the  Apple  iPod  Touch.  During  the  AAB,  MG  Justice  (Research 
Development  and  Engineering  Command  [RDECOM]  Commanding  General)  was  given  a 
demonstration  of  the  HEAT  application.  He  was  impressed  with  the  capability,  reached  into  his 
pocket  to  retrieve  his  Android  device,  and  asked  if  the  application  would  run  on  it.  Thus,  the 
impetus  later  that  year  to  acquire  an  Android  based  development  phone  and  host  the  HEAT 
capability  on  it. 
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3.  Development  Environment 


As  Android  applications  are  written  in  the  Java  programming  language,  it  is  fairly 
straightforward  to  develop  them.  At  least  one  Integrated  Development  Environment  (IDE)  for  a 
Windows  based  platform  (Eclipse,  Galileo  release)  includes  the  capability  to  download  and 
install  an  Android  development  tool  (ADT)  plug-in.  The  ADT  extends  the  eapabilities  of  the  IDE 
sueh  that  a  coding  text  editor,  debugger,  compiler,  graphical  user  interface  (GUI)  builder  and 
Android  Smartphone  simulator  are  available.  The  simulator  includes  several  versions  of  the 
Android  operating  system  as  well  as  various  screen  sizes,  thus  code  can  be  developed  and  tested 
independent  of  an  actual  device.  However,  it  is  always  best  to  test  a  “final”  application  on  one  or 
more  devices,  thus  two  Android  Developer  Smartphones  were  purchased  for  development  and 
testing  purposes.  Unlike  Apple  iPod/iPhone  application  development,  it  is  not  necessary  to 
purchase  an  annual  user  lieense.  Instead,  the  apps  can  be  uploaded  to  the  smartphone  via  a 
Universal  Serial  Bus  (USB)  eable  eonnected  to  the  device.  It  is  also  possible  to  attach  the 
application  Android  Package  (“apk”  file)  to  an  email  and  then  open  email  on  the  smartphone  and 
directly  install  the  app. 

Eor  development,  two  identical  Android  Developer  2  Smartphones  were  purchased.  These 
phones  came  with  a  recent  version  of  the  Android  operating  system  but  without  a  subseriber 
identity  module  (SIM)  card  which  is  required  for  cell  phone  calls.  The  developer  phones 
purchased  include  the  following  features: 

•  3. 17-ineh  diagonal  touehscreen  with  480  x  320  pixel  resolution 

•  2.2  X  0.6  X  4.5  ineh  size 

•  WiPi  802. 1  l(b/g)  and  Bluetooth  wireless  communieation 

•  Web  browser 

•  528  MHz  proeessor 

•  micro  Secure  Digital  (SD)  memory  slot 

•  3  mega-pixel  auto  foeus  eamera 

•  192  megabyte  (MB)  random  aceess  memory  (RAM);  512  MB  EEASH  memory 

•  Android  version  1 .6  operating  system 

Although  the  proeessor  speed  and  amount  of  RAM  available  are  certainly  more  than  adequate  for 
simple  weather  apps,  there  are  considerations  that  must  be  aecounted  for  when  designing  the 
software.  The  primary  issue  has  to  do  with  the  screen  size  and  the  faet  that  all  screen  input  is  via 
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a  user"s  finger  tips.  Thus,  in  designing  the  GUI,  eare  must  be  taken  regarding  the  size  of  input 
fields.  Also,  output  sereens  must  not  eontain  too  mueh  information  or  use  too  small  of  a  font. 


4.  Considerations  for  Military  Use 


There  are  a  number  of  advantages  in  developing  and  deploying  apps  on  the  Android  based 
smartphones: 

•  Low  cost.  A  new  Android  Dev  Phone  2  ean  be  purehased  for  less  than  $400.  Compared  to 
mobile  deviees  that  may  be  eustom  designed  and  developed  for  military  operations,  this  is 
a  very  reasonable  eost.  Although  these  deviees  may  not  be  as  ruggedized  as  other  deviees 
eurrently  in  use  by  the  military,  it  would  seem  that  the  low  eost  per  unit  justifies  their  use. 
Due  to  their  light  weight  and  size,  they  logistieally  have  a  small  footprint  and  it  seems 
likely  that  spares  eould  be  readily  available. 

•  Soldier  familiarity .  It  is  likely  that  a  signifieant  pereentage  of  Soldiers  (espeeially  new 
reeruits)  are  familiar  with  the  use  of  Android  Smartphones  and  their  operation.  This 
translates  into  redueed  training  eosts.  Also,  being  familiar  with  the  deviees  means  that  the 
Soldier  is  more  likely  to  use  the  deviee  and  assoeiated  apps. 

•  Relatively  large  storage  space.  The  Android  Dev  Phone  2  eomes  equipped  with  512  MB  of 
memory  as  well  as  a  miero  SD  eard  memory  slot  whieh  ean  aeeommodate  an  additional  32 
gigabyte  (GB)  of  memory.  This  amount  of  storage  provides  the  eapability  to  store  large 
weather  related  gridded  databases,  satellite  imagery,  and  even  video.  Gridded  weather  or 
weather  effeets  databases  ean  be  used  to  provide  high  resolution  (both  spatially  and 
temporally)  input  data  required  by  some  weather  related  apps. 

•  Built-in  rechargeable  battery.  The  Android  Dev  2  Phone  has  a  built-in  lithium-ion  battery 
that  may  be  replaeed  by  the  user  (unlike  Apple  iPod  Toueh  deviees),  thus  spare  batteries 
ean  be  earried.  If  there  is  only  sporadie  use  of  the  deviee,  a  single  eharge  ean  last  for  many 
days  of  operation. 

On  the  other  hand,  there  is  at  least  one  potential  eoneem  about  the  use  of  these  deviees: 

•  Lack  of  secure  and  long  range  wireless  communications .  The  effeetive  range  for  Bluetooth 
eommunieations  is  on  the  order  of  several  meters  while  Wi-Fi  (in  an  open  environment) 
may  be  several  hundred  meters  to  up  to  a  few  kilometers.  This  is  obviously  not  suffieient 
for  military  eommunieations  baek  to  a  remote  server  whieh  may  be  tens  of  (or  more) 
kilometers  away.  Thus,  reeeiving  and  transmitting  eritieal  information  is  a  eoneem.  This 
ean  be  mitigated  to  some  extent  by  developing  apps  that  only  require  simple  loeally  entered 
weather  inputs  (or  possibly  using  one  of  the  available  high  quality  handheld  weather 
sensors).  Or,  in  the  case  of  apps  that  require  more  complex  input  (e.g.,  high  resolution 
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gridded  data),  it  may  be  possible  to  download  an  entire  database  of  weather  or  weather 
effeets  information  to  the  deviee  while  at  the  garrison  or  taetieal  operations  eenter  (TOC) 
for  use  during  the  day.  Ideally,  however,  there  will  eventually  be  longer  range  seeure 
wireless  eommunieation  eapabilities.  Note  that  this  is  also  a  shorteoming  of  PDAs  and 
Apple  iPhones  and  iPod  Touehes  without  eellular  serviee  as  well. 


5.  Prototype  App 


Attesting  to  the  relative  ease  in  learning  the  Android  Smartphone  development  environment,  a 
prototype  HEAT  was  ported  from  an  iPod  Toueh  implementation  in  just  a  few  months.  This 
involved  a  eomplete  rewrite  of  the  GUI  to  the  smartphone  using  the  interfaee  builder.  While  not 
diffieult,  it  did  require  the  majority  of  the  time  due  to  starting  from  serateh  with  different  GUI 
elements  (to  a  eertain  extent),  and  the  “eallbaeks”  to  the  eomputational  algorithms.  Additional 
effort  was  required  related  to  learning  the  IDE  and  making  minor  modifieations  to  the 
algorithms.  There  were  no  issues  with  switehing  from  the  smartphone  simulator  environment  to 
the  aetual  Android  Dev  Phone  2. 

The  HEAT  app  was  initially  developed  to  address  the  issue  of  heat  stress  injuries  in  the  military. 
A  reeent  study  (3)  indieated  that  annually,  there  are  over  200  injuries  requiring  hospitalization 
from  heat  stress  resulting  in  an  average  of  almost  2  deaths.  Henee,  the  rationale  for  developing 
sueh  an  app  and  making  it  available  on  a  mobile  deviee.  Current  plans  are  to  initiate  a  validation 
study  of  the  Wet  Bulb  Globe  Temperature  (WBGT)  algorithm  (4)  as  implemented  in  HEAT  and 
then  transition  to  the  Army  Marketplaee  for  evaluation  and  transition  to  the  Soldier  (the  WBGT 
parameter  is  eritieal  in  determining  the  HEAT  output  values).  Eollowing  are  the  various  input 
and  output  sereens  with  a  diseussion  of  the  various  GUI  elements  and  potential  future 
enhaneements. 

5.1  Launch  Screen 

Eigure  1  below  is  the  initial  sereen  that  is  displayed  upon  startup  of  the  Android  Smartphone. 
Eaeh  app  is  represented  by  an  ieon.  Simply  tapping  the  ieon  launehes  that  applieation.  The 
HEAT  app  is  the  seeond  ieon  from  the  left  in  the  third  row  from  the  top. 
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Figure  1.  Initial  startup  screen. 


5.2  SITE  View 

The  first  screen  (known  as  a  “view”)  of  the  app  that  is  displayed  upon  tapping  the  app  icon  is  the 
Site  view.  The  HEAT  app  is  a  multi-view  application  with  a  tab  bar  (top  of  screen).  The  user 
enters  the  required  inputs  (default  values  always  available)  by  tabbing  through  the  various  views 
and  selecting  the  fields  that  he  wishes  to  modify.  Numeric  inputs  are  checked  for  appropriate 
values  with  a  pop  up  warning  in  the  event  that  a  value  is  out  of  range  or  invalid  (e.g.,  null).  Upon 
exit,  default  values  are  assigned  to  the  values  that  were  last  entered  via  data  persistence.  These 
values  are  displayed  to  the  user  the  next  time  the  application  is  invoked.  Text  field  inputs 
(latitude  and  longitude  fields),  labels  (“Latitude”,  etc.),  “Spinners”  (latitude  and  longitude 
hemisphere  fields),  a  DatePicker  and  TimePicker,  and  GUI  elements  are  all  used  in  this  view.  A 
picker  functions  by  the  user  tapping  the  “+”  or  selectors  above  and  below  the  displayed 
values  to  increment  or  decrement  the  values.  The  date/time  defaults  to  the  current  device  time  as 
initially  set  up  by  the  user. 

If  the  device  had  a  GPS  capability,  the  default  altitude  and  longitude  values  could  be 
automatically  filled  in. 

5.3  MET  View 

The  next  view  in  the  sequence  of  tabs  is  the  MET  (meteorological)  view  shown  in  figure  2 
below.  This  view  is  used  to  input  local  weather  conditions.  As  with  the  SITE  view,  this  view 
consists  of  labels,  text  fields  and  a  spinner  (cloud  type).  Handheld  weather  sensors  would 
typically  be  used  in  the  field  to  determine  the  weather  input  values  (wind  speed,  temperature  and 
relative  humidity)  while  a  simple  visual  observation  would  provide  the  cloud  input  information. 
As  the  smartphone  device  utilized  has  a  Bluetooth  wireless  capability,  automated  ingest  of  the 
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weather  data  via  remote  conneetion  to  the  sensor  (also  equipped  with  Bluetooth)  will  be 
investigated  in  the  near  future. 


Wind  mph  Humidity 
Temperature  deg  F 

Cloud  Amount  Q  tenths 
Cloud  Type: 


High  (thick  cirrus) 


Figure  2.  MET  tab  view. 


5.4  WORK  View 

Next  is  the  WORK  view  (figure  3),  used  to  input  the  details  about  the  Soldief's  work  rate  and 
elothing  eonfiguration.  Obviously  the  higher  the  work  rate,  the  shorter  the  work/rest  eycle  and 
continuous  work  time  will  be,  all  other  inputs  being  the  same.  Note  that  spinner  controls  are  used 
for  both  of  the  inputs.  Descriptions  of  the  various  work  rates  are  available  in  the  bottom  half  of 
the  screen. 


AC9  RlRDS  3:08  PM 


Clothing 


Work 

Work  Info: 

Easy:  Walklr^g  hard  surface  at  2.5  mph,  30  lb 
load:  Weapon  maintenance;  Markmanship 
training;  Drill  and  ceremony 

Moderate:  Walking  loose  sand  at  2.5  mph.  no 
load;  Walking  hard  surface  at  3.5  mph.  40  lb 
load;  Calisthenics;  Patrolling  Individual 
movement  techniques,  le,  low  crawl,  high 
crawl 

Hard:  Walking  hard  surface  at  3.5  mph,  over 
40  lb  load;  Walking  loose  sand  at  2.5  mph 
with  load;  Field  assaults 


Body  Armor 


Figures.  WORK  view. 
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There  is  one  notable  differenee  between  the  Android  and  Apple  tabbed  view  (as  well  as  of 
Windows  Mobile  devices  (e.g.,  personal  digital  assistants)).  Instead  of  having  a  “More”  entry  to 
indicate  additional  views  as  with  the  Apple  layout,  the  Android  developer  is  limited  to  the 
number  of  tabs  that  will  fit  into  the  tabbed  region  at  the  top  of  the  screen.  Windows  Mobile 
devices  have  right  or  left  arrows  to  indicate  additional  choices.  Both  the  Windows  Mobile  and 
Apple  setups  are  more  flexible  than  the  Android  implementation  of  tabs. 

Adding  GUI  elements  to  the  view(s)  can  be  done  either  via  dragging  and  dropping  elements  from 
the  GUI  pallet  or  by  directly  editing  an  xml  file  associated  with  each  view.  The  xml  file  provides 
the  user  with  more  control  of  the  size  and  location  of  the  widgets  than  the  drop  and  drag  method. 
The  xml  file  also  specifies  the  internally  used  name  of  the  widget(s)  which  are  then  referenced  in 
the  Java  code  to  access  and  set  variables  (if  any)  associated  with  the  widget  (e.g.,  the  numeric 
input  elements).  Having  the  GUI  portion  of  an  application  independent  from  the  computational 
algorithms,  aids  in  the  maintenance  of  the  code.  It  also  leads  to  reusability  of  the  code. 

5.5  RSLTS  View 

After  completing  input  for  all  desired  parameters,  the  user  can  then  select  the  “RSLTS”  tab  to 
initiate  the  internal  computations  and  display  the  results.  This  view  contains  the  heat  stress 
output  parameters  as  seen  in  the  figure  4  below.  These  values  are  computed  based  on  the  user 
selected  inputs  via  the  previous  views.  The  computation  and  display  is  instantaneous.  Output  text 
fields  in  this  view  are  read  only,  i.e.,  the  user  cannot  modify  the  values  by  tapping  those  GUI 
elements.  As  shown,  output  variables  are  extensive  and  provide  useful  guidance  to  the  user.  The 
WBGT  represents  an  estimate  of  the  WBGT  that  is  a  legacy  parameter  that  has  been  used  by  the 
Army  for  many  years  to  estimate  heat  stress  susceptibility. 


QB*  3:08  PM 

HEAT 

1  sm  i  1  MET  ^  WORA  I  '  INFO  1 

Work/Rest 

Wo  rk/Rest  Cycle 

minutes 

Water  Intake 

qt/hr 

Continuous  Work 

Work  Duration 

minutes 

Water  Intake 

qt/hr 

Computed  WBGT 

degF 

NOTES:  Wo rk/Rest  cycles  are  per  hour;  NL(Work/ 
Rest)  -  No  limit  to  work  time  per  hour;  NL 
(Continuous  work)  -  Can  sustain  work  for  at  least  4 
hrs;  Daily  fluid  intake  should  not  exceed  12qts; 
Hourly  fluid  Intake  should  not  exceed  15qts 


Figure  4.  RSLTS  view. 
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The  work/rest  cycle  is  based  on  a  60  min  period  while  the  continuous  work  value  represents  the 
maximum  time  that  is  advised  for  a  one  time  work  effort  (after  which  the  Soldier  is  given  a 
sufficient  time  to  fully  recover  before  being  assigned  a  work  load  again). 

5.6  INFO  View 

The  last  view  available  is  the  info  screen  shown  in  figure  5.  This  provides  a  means  to  display 
background  information,  caveats,  acknowledgements,  etc.,  about  the  product.  It  is 
straightforward  to  add  custom  logos  (e.g.,  the  ART  logo  in  the  top  center)  to  any  view  by  simply 
creating  and  saving  your  graphics  as  portable  native  graphics  (.png)  images  and  then  inserting 
and  positioning  them  via  the  GUI  builder  or  specifications  directly  in  the  xml  file  as  previously 
referenced. 


AQ 

3:08  PM 

.  heat  ,  _  _ 

1  t'MFT 

i  I  WORK  I  '  RSIT?  B’!-,;  I 

Hot  Environment  Assessment  Tool 
(HEAT) 

Version  1.0 
December  2010 

Army  Research  Laboratory 
White  Sands  Missile  Range,  NM 


Point  of  Contact; 

David  Sauter 

david.sauter®  us.army.mil 


Figure  5.  INFO  view. 


6.  Browser  Capability 


The  smartphone  used  has  a  Web  browser  capability  built  in  which  will  allow  access  to  any 
number  of  browser  applications  over  the  internet,  assuming  there  is  an  internet  connection  (e.g., 
via  WiFi).  Many  developers/companies  tailor  their  Web  pages  so  that  a  specific  configuration  is 
automatically  loaded  for  mobile  devices  and  their  smaller  screen  sizes.  An  internally  developed 
browser  application  based  on  the  Adobe  Flex  framework  will  be  tested  by  ART  on  the 
smartphone  later  in  201 1  which  will  determine  whether  the  device  is  compatible  with  the 
application. 
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Although  no  attempt  was  made  to  consume  a  Web  service  on  the  device,  an  internet  search  of  the 
capability  turned  up  a  multitude  of  sites  indicating  that  it  is  certainly  possible  to  do  so.  Although 
Android  does  not  appear  to  support  web  service  calls  directly,  there  are  readily  available  third 
party  solutions  (e.g.,  kSOAP)  that  will  allow  Web  services  to  be  consumed  by  the  Android 
device.  Web  services  represent  one  of  the  latest  and  most  widely  accepted  client-server 
technologies  for  running  processes  remotely  or  retrieving  remote  data.  ARL  is  currently 
developing  an  enterprise  application  that  will  utilize  Web  services  for  the  client-server 
interaction.  Once  complete,  ARL  will  test  and  evaluate  on  the  smartphone  device. 


7.  Relational  Database 


Storing  and  retrieving  data  to/from  large  datasets  is  more  efficient  when  utilizing  relational 
databases  as  opposed  to  simple  text  files.  More  than  one  of  Battlefield  Environment  Directorate"s 
weather  related  applications  rely  on  relational  databases,  thus,  if  it  is  desired  to  host  any  of  them 
on  an  Android  Smartphone,  a  relational  database  capability  would  be  necessary.  Fortunately,  the 
Android  Smartphones  include  the  SQLlite  relational  database.  Thus,  in  theory,  large  databases 
such  as  the  Integrated  Weather  Effects  Decision  Aid  (IWEDA)  rules  database  and  the  Gridded 
Meteorological  Database  (GMDB)  could  be  hosted  and  used.  SQEhe  even  supports  the  storage 
of  binary  large  objects  (,blobs'')  which  the  GMDB  makes  use  of  The  advantage  of  having  this 
capability  on  the  mobile  device  means  that  the  IWEDA  and/or  GMDB  could  be  synchronized 
locally  on  the  Android  Smartphone  so  remote  wireless  communications  would  not  have  to  be 
relied  upon.  Then  IWEDA,  as  well  as  any  apps  that  require  access  to  the  GMDB  (e.g.,  weather  or 
weather  impacts  visualization,  chem/bio  diffusion  models,  etc.),  could  be  run  locally.  It  is 
desirable  that  development  of  a  simple  app  to  test  and  benchmark  the  database  capabilities  (e.g., 
blob  create,  read,  update  and  delete,  table  creation  and  query,  data  entry,  etc.)  be  undertaken  at 
some  point  to  evaluate  the  potential  for  weather  app  support.  Certainly  the  storage  capabilities 
(up  to  32  GB  on  a  microSD  card)  of  the  devices  will  support  large  relational  databases. 


8.  Conclusion 


A  number  of  mobile  computing  devices  have  flooded  the  consumer  market  over  the  last  decade. 
These  include  PDAs,  Apple  iPod  and  iPhone  devices,  and  smartphones  (e.g.,  running  either  the 
Windows  Mobile,  the  Android  operating  system,  or  other).  This  has  created  an  opportunity  to 
leverage  this  technology  for  military  advantage,  particularly  for  dismounted  Soldiers.  A  number 
of  applications  have  been  developed  for  one  or  more  of  these  devices  (one  has  been  fielded). 
With  increasing  options  and  capabilities,  the  opportunity  to  provide  even  more  advanced 
applications  for  the  military  exists  and  will  continue  to  be  exploited.  In  FY 1 1 ,  an  Android  based 
tablet  device  will  be  purchased  and  its  capabilities  evaluated  by  ARL. 
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List  of  Symbols,  Abbreviations,  and  Acronyms 


AAB 

All  American  Bowl 

ADT 

Android  development  tool 

apps 

applications 

ARL 

U.S.  Army  Research  Eaboratory 

GB 

gigabyte 

GMDB 

Gridded  Meteorological  Database 

GUI 

graphical  user  interface 

HEAT 

Hot  Environment  Assessment  Tool 

IDE 

Integrated  Development  Environment 

IWEDA 

Integrated  Weather  Effects  Decision  Aid 

MB 

megabyte 

MET 

meteorological 

PDAs 

personal  digital  assistants 

RAM 

random  access  memory 

RDECOM 

Research  Development  and  Engineering  Command 

SD 

Secure  Digital 

SIM 

subscriber  identity  module 

TOC 

tactical  operations  center 

USB 

Universal  Serial  Bus 

WBGT 

Wet  Bulb  Globe  Temperature 
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No,  of 

Copies  Organization 

1  ADMNSTR 

ELEC  DEFNS  TECHL  INFO  CTR 
ATTN  DTIC  OCP 

8725  JOHN  J  KINGMAN  RD  STE  0944 
FT  BELVOIR  VA  22060-6218 

1  CD  OFC  OF  THE  SECY  OF  DEFNS 

ATTN  ODDRE  (R&AT) 

THE  PENTAGON 
WASHINGTON  DC  20301-3080 

I  HC  US  ARMY  RSRCH  DEV  AND  ENGRG  CMND 
ARMAMENT  RSRCH  DEV  &  ENGRG  CTR 
ARMAMENT  ENGRG  &  TECHNLGY  CTR 
ATTN  AMSRD  AAR  AEF  T  J  MATTS 
BLDG  305 

ABERDEEN  PROVING  GROUND  MD  21005-5001 

1  HC  US  ARMY  INFO  SYS  ENGRG  CMND 
ATTN  AMSEL  IE  TD  A  RIVERA 
FT  HUACHUCA  AZ  85613-5300 

1  HC  COMMANDER 

US  ARMY  RDECOM 

ATTN  AMSRD  AMR  W  C  MCCORKLE 

5400  FOWLER  RD 

REDSTONE  ARSENAL  AL  35898-5000 

1  HC  US  GOVERNMENT  PRINT  OFF 

DEPOSITORY  RECEIVING  SECTION 
ATTN  MAIL  STOP  ID  AD  J  TATE 
732  NORTH  CAPITOL  ST  NW 
WASHINGTON  DC  20402 

1  HC  DIRECTOR 

US  ARMY  RSRCH  LAB 
ATTN  RDRL  ROE  V  W  D  BACH 
PO  BOX  1221 1 

RESEARCH  TRIANGLE  PARK  NC  27709 

I  HC  US  ARMY  RSRCH  LAB 

2  CDS  ATTN  RDRL  CIE  M  D  SAUTER 

WHITE  SANDS  MISSILE  RANGE  NM  88002-5501 

3  HCS  US  ARMY  RSRCH  LAB 

ATTN  IMNE  ALC  HRR  MAIL  &  RECORDS  MGMT 
ATTN  RDRL  CIO  LL  TECHL  LIB 
ATTN  RDRL  CIO  MT  TECHL  PUB 
ADELPHI  MD  20783-1197 
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